iT邦幫忙

2021 iThome 鐵人賽

DAY 14
0
Software Development

MYSQL-相關實務操作學習紀錄系列 第 14

Day.14 Crash Recovery- InnoDB 架構 -> MYSQL 二階段提交(2PC) _2

  • 分享至 

  • xImage
  •  

有關於實際業務上對於數據要求的重要性,以下參數設定的寫入策略搭配會對性能與安全度產生不同的影響。

相關參數內容:

innodb_flush_log_at_trx_commit

  • 控制日誌緩衝區內容如何寫入和刷新到磁盤策略參數: innodb_flush_log_at_trx_commit (選項: 0,1,2)

看一下大致流程,才會懂下面提到的參數設置意義喔!!/images/emoticon/emoticon31.gif

(內存中的日誌緩衝)                                        (磁盤上)        
redo log buffer -寫入-> OS cache  --呼叫fsync()刷盤--> redo log file 

ps. 呼叫fsync()操作指的是將OS buffer中的日誌刷到磁碟上的redo log file中數據持久化。

設 0 - 每隔1秒才將日誌緩存區中的日誌寫入到os cache並呼叫fsync()刷新到磁盤上的redo log file。

(雖然效率高但資料安全性低,因為1秒的數據有可能因為mysql崩潰而丟失)

設 1 - 每次事務提交時都會將日誌緩存區中的日誌寫入os cache並呼叫fsync()刷新到磁盤上的redo log file。

(資料安全性高,因為只要提交就會更新磁盤資料所以不會有丟失的狀況,不過因為每次提交都刷新磁盤所以效能相對最差)

設 2 - 每次事務提交時把日誌緩存區的日誌寫入os cache,不會同時刷新到磁盤上,而是每秒呼叫fsync()刷到磁盤上的redo log file。

(比設為0安全每秒執行刷新到磁盤,在操作系統崩潰or系統斷電的狀況下才可能發生那一秒的數據丟失)


sync_binlog

  • 控制MySQL服務器將binlog同步到磁盤的頻率: sync_binlog (選項: 0,1,N個)

寫入流程如下,先了解才會懂下面提到的參數設置意義喔!!/images/emoticon/emoticon31.gif

                                         事務提交(commit)
事務執行中(尚未commit) -寫入-> binlog cache -----寫入-----> os cache -呼叫fsync()刷盤--> binlog

設 0: 在事務提交時不會將二進制日誌同步到磁盤。(等於不會fsync()刷盤)

設 1: 在事務提交時會將二進制日誌同步到磁盤。(最安全的設置,且保證沒有事務從二進制日誌中丟失)

設 N(>1): 當提交的日誌組到達設定值N時,會將二進制日誌同步到磁盤。


  • 如何去取捨兩者參數之間的搭配有關於:

    • 對數據安全性要求(高低)
    • 磁盤寫入能力(好壞)
    • 主從延遲落後問題

下集預告: 了解完以上內容後明天就正式講解二階段提交流程囉!


上一篇
Day.13 Crash Recovery - InnoDB 架構 -> MYSQL 二階段提交(2PC) _1
下一篇
Day.15 Crash Recovery- InnoDB 架構 -> MYSQL 二階段提交(2PC) _完
系列文
MYSQL-相關實務操作學習紀錄30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言